Skip to content

implementing surface transform and related tests#4

Draft
birajstha wants to merge 2 commits into
mainfrom
surface-transform
Draft

implementing surface transform and related tests#4
birajstha wants to merge 2 commits into
mainfrom
surface-transform

Conversation

@birajstha
Copy link
Copy Markdown
Collaborator

Related to this issue

image

@birajstha birajstha self-assigned this Sep 22, 2025
Copy link
Copy Markdown
Collaborator

@kaitj kaitj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @birajstha - think this is a good first pass at it. Left a few notes (don't necessarily need action right now), a few comments / suggestions, and also had a few questions.

Feel free to either implement the changes here or open a new PR on the skeleton repo with responses here (just make sure to close this if you do this 😅)

Comment thread pyproject.toml
"nilearn",
"pytest>=8.3.5",
"packaging>=25.0",
"pandas>=2.0.3",
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is pandas required - if this is pinned because a minimum version is required should include a comment about it

Comment thread pyproject.toml
"packaging>=25.0",
"pandas>=2.0.3",
"niwrap>=0.6.3",
"styxsingularity>=0.5.1",
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, this isn't needed anymore because niwrap can handle all of the the runner logic as of 0.6.x. I would look into the use_* commands from niwrap.

As a side note, aside from 1-off scripts, when building packages with niwrap, would ultimately want to be able to support all runners (e.g. docker, singulartity, etc.)

Comment thread pyproject.toml
"nibabel>=3.0.0",
"nilearn",
"pytest>=8.3.5",
"packaging>=25.0",
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is packaging required?

Comment thread pyproject.toml
"nilearn"
"nibabel>=3.0.0",
"nilearn",
"pytest>=8.3.5",
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For testing, would create a separate dependency group with just test dependencies so that these aren't unnecessarily installed if not testing / developing.

Comment thread pyproject.toml
description = "A toolbox for projecting, resampling, and comparing brain maps"
readme = "README.rst"
requires-python = ">=3.8"
requires-python = ">=3.10"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 - would also note in the commit / pr comments that this change is due to <py3.10 no longer being supported (EoL)

# Add more tuples here for additional test cases
]
)
def test_surface_sphere_project_unproject(sphere_in, sphere_project_to, sphere_unproject_from, sphere_out):
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note for now, we may need to think about pulling in the files to do the testing here.

set_global_runner(my_runner)


@pytest.mark.parametrize(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think the parametrization is necessary here unless you plan to add additional tests. Otherwise would just have these coded in the test.

result = surface_sphere_project_unproject(
sphere_in, sphere_project_to, sphere_unproject_from, sphere_out
)
assert os.path.exists(result)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will fail because result is an object. Instead, you will want to test that result.sphere_out exists.

------------------------
S1200 to Yerkes19 to D99
------------------------
sphere_in = S1200_aligned_t-_Yerkes19 (Input)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing an "o" in to-

assert os.path.exists(result)

# check if the output file has the same number of vertices as the input file
assert nib.load(result).darrays[0].data.shape == nib.load(sphere_in).darrays[0].data.shape
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 comments here:

  1. The loading will raise an error, again because result is an object.
  2. The assertion has the possibility of failing here. With surface transformations across different spaces like this, it isn't guaranteed that the input and output transformations contain the same number of vertices. Instead, it would be better to check:
    a. The output sphere has the same shape as the target sphere
    b. The spatial locations of the vertices are near identical to the target sphere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants